Subject: Header Formats and Usage

From: [email-masked] (Paul Brittain)
Date: Wed, 8 Jun 94 19:21:05 BST

Frank/Lakshman

I fear that the spirit of the message format issue I raised has been lost in
your subsequent discussions, which are coming at the problem from a different
angle to that of my original mail.  This mail aims to clarify my original
points and to add to the discussion on related, but separate, issues.

Current SSP usage
=================

We have observed from Sniffer traces of traffic between two 6611s running MPNP
1.2 and subsequent interoperability testing that they currently _REQUIRE_ the
x1D message to use a 16-byte INFOFRAME format header, and the x_BUSY plus
TEST_CIRCUIT messages to use 72 byte headers.  Since this is not obvious from
either the RFC or previous discussion on this RIGlet, it needs to be documented
as part of trying to provide the data necessary for backwards-compatibility.

I don't think the need for such documentation should be contentious, hence can
we separate it from the discussion of whether the header formats remain the
same or need to be changed?

Header format changes
=====================

Moving on to your points about the header formats themselves (as opposed to how
they are currently used), we are worried that a sweeping change here may render
backwards compatibility impossible.  That does not mean that we are totally
opposed to a change in the headers as you suggest, but it seems essential that
the header used on CAP-EX exchange remain in the same format as the existing
control header.  With this restriction, a standard node can safely determine
whether it has an standard or pre-standard partner using the CAP-EX, as
the pre-standard partner should be able to skip any unrecognised control-header
message it receives.

If the CAP-EX keeps the the control-header format (+/- the possible
use of some reserved fields), the use of any new features that require
different header formats could be negotiated as part of the CAP-EX without the
need to decide what those features and formats will be at this stage (unless
anyone wishes to add such items into release 1).

Note, as always, that a standard DLSw can detect a pre-standard partner from
the lack of a CAP-EX and may elect to drop the connection to this partner.
However it would make migration from pre-standard implementations already in
the field considerably more difficult if we do not preserve the control header
for the CAP-EX.

Please post your views on the above.

Other issues/new FSMs
=====================

My apologies for not yet having had the time to post any feedback on Steve's
new FSMs or the other open issues.  I will do so later this week(end?) to give
time for further discussion before June 17.

Paul Brittain
Data Connection.

---

From: Lakshman Garikapaty <[email-masked]>
Date: Wed, 8 Jun 94 17:26:56 EDT

Paul,

>same or need to be changed?
   
  Did't mean to side track your point but i have no idea what x1D msg. is?
and when should we expect or send this message. I am also confused that 
for interoperablity testing they (who?) require to implement this msg. 
This is new to me. I guess more information is needed here. 

   There is no contention with respect to documentation but i think we 
should not clutter the data flow with backward compatiblity line items. 
We need a new section or appendix which details 6611 interoperablity. In 
this section we need all the messages that 6611 is sending that are not
listed and which states effect etc. should be documented. Makes sense?

Lakshman.